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Sentencias de programación 
(parte I) 


| Comenzamos este nuevo número de 


Rendermanía con las llamadas sentencias 
de programación de «POV», Actuaremos así 
por tres razones: la primera porque existen 
lectores que confiesan no comprender su 


funcionamiento, la segunda porque el 


dominio de estas sentencias es necesario ntes de empezar a.es- 
tudiar el proceso de 

para poder aprovechar al máximo las creación de anima- 
ciones con «POV>» 
posibilidades de construcción y animación conviene repasar el 
funcionamiento de 
que ofrece «POV» y la tercera, porque ya las sentencias “de programación” de 
«POV». Además, aunque ya hemos 
empieza a hablarse de los futuros cambios hablado de Hif, itwhile y de otras sen- 
tencias de este tipo en números ante- 
que en este apartado van a aparecer con la riores, el caso es que sigue habiendo 
un gran número de usuarios que —aun 
próxima versión de «POV». siendo talentosos pov-artistas— no 


comprenden su funcionamiento. Y, sin 
embargo, la importancia de estas sen- 
tencias es enorme. 

Con ellas se pueden levantar ciuda- 
des, disponer ejércitos, crear estructu- 
ras complejas para naves espaciales, 
etc. De hecho, les hemos concedido 
una importancia mucho mayor de la 
que otorga a las sentencias que se utili- 
zan en «POV» para crear objetos. ¿Por 
qué? Porque en «POV» no es indispen- 
sable que creemos los objetos que vana 
aparecer en la escena con su lenguaje 
escénico. Se pueden emplear progra- 
mas como «3D Studio», «Imagine», 
«Spatch» o «Rhino» para crear los. ob- 
jetos y luego exportarlos a «POV» y 
renderizar las escenas desde este últi- 
mo. Como recordaréis, «Spatch» y 
«Rhinoceros» pueden exportar directa- 
mente sus modelos a «POV», mientras 
que para hacer lo propio desde «3D 
Studio» e «Imagine» deberemos em- 
plear utilidades —ya publicadas aquí en 
números anteriores- como 3ds2pov y 
3dto3d, respectivamente. 

Este ha sido, además, el método de 
trabajo empleado enlos últimos núme- 
ros de Rendermanía y puede resumirse 
en los siguientes pasos: 

1) Uso de un modelador para crear 
los modelos básicos de la escena. 

2) Exportación de estos a «POV». En 
este paso el programa empleado creará 
uno o más ficheros ASCII para guardar 
los modelos en un formato inteligible 
para «POV». normalmente utilizando 
mesh, triangle, smooth_triangle y otras 
sentencias del lenguaje escénico de 
«POV». 

3) Empleo de un editor de textos pa- 
ra crear los ficheros de escena. En ellos 
se escribirán declaraciones utilizando 
el lenguaje de «POV» para situar la cá- 


mara, las luces y los objetos importa- 
dos (que se hallan almacenados en 
otros ficheros a los que se hace referen- 
cia con la sentencia Htinclude). También 
se crearán desde aquí las texturas pro- 
cedurales necesarias. 

4) Pruebas y pruebas de render. 

Como veis, estos pasos sólo requie- 
ren Comprender una parte de lo que el 
lenguaje escénico de «POV» puede ha- 
cer. No es preciso conocer las primiti- 
vas de «POV> para crear objetos, pero 
sí es necesario saber cómo funcionan 
las transformaciones espaciales y cómo 
se sitúan la cámara, los objetos y las lu- 
ces. También es conveniente, aunque 
no imprescindible, comprender cómo 
funcionan las texturas procedurales. 
(Nota: todas estas cosas han sido expli- 
cadas en los números 16, 17, 18 y 19 
de Rendermanía y recomendamos a los 
usuarios novatos de «POV» leer dichos 
números si quieren entender algo). 

Esta filosofía nos permitirá disfrutar 
de las ventajas visuales que conlleva el 
trabajo con los modeladores interacti- 
vos que utilizan ventanas al tiempo que 
podremos gozar, también, de las venta- 


jas que «POV» posee con respecto a la 
s. Aquí 
refiriendo ¡1 las sentencias 


mayoría de dichos progra 
nos estam 
con que cuenta «POV> para crear mag- 
níficas texturas procedurales, a la posi- 
bilidad de situar miles de objetos poli- 
gonales sin excesivo gasto de memoria 
=sentencia mesh-, a la calidad de su 
render, etc. 

Por otra parte. las sentencias de pro- 
gramación no son difíciles de utilizar, 
aunque pueden suponer un pequeño es- 
fuerzo para quienes nunca hayan traba- 
Jado con lenguajes de programación. 


Bucles con while 
Indiscutiblemente la colocación de 
objetos puede ser —con independencia 
del programa que se esté empleando- 
una de las tareas más molestas en la 
construcción de ciertas escenas. Crear 
imágenes como las aparecidas en las 
portadas de los números 14 y 17 podría 
ser una auténtica pesadilla si no dispu- 
siéramos de alguna ayuda que nos evi- 
tara colocar manualmente cada modelo 
dentro de la escena. Probablemente, 
pensaréis que raramente es preciso 


crear escenas con tantos ele- 
mentos repetidos, pero lo 
cierto es que resulta posible 
imaginar muchos ejemplos 
de colocación tediosa de ob- 
jetos. Por ejemplo, los tacos 
de las llantas de una bicicleta 
(o los radios de sus ruedas), 
las ventanas de un edificio, 
las columnas de un templo, 
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Figura 1: “ejemplos sencillos de uso de f+while” 


llejemplo A 

Hideclare nz=0 

Hwhile(nz<40) 
object[Bcolum!150_300s1 Iranslate<0,0,nz*150>) 
object[Bcolum150_300s1 translate<450,0,nz*150>)] 
Hideclare nz=nz+1 

ttend 


(Ejemplo B: este trozo de código hace lo mismo que el del ejemplo anterior, 
pero es mas útil. 
tideclare nz=0 
tideclare galerial_3x3y=union( 
twhile(nz<40) 
object[ Bcolum150_300s1 translate<0,0,nz*150>) 
object[Bcolum150_300s1 translate<450.0.nz* 150>) 
tideclare nz=nz+1 
Htend 


de instrucciones compren- 
didas entre las sentencias 
twhile y Htend. A esta lista 
de sentencias la llamare- 
mos el cuerpo del bucle y 
todas ellas se repetirán 
tantas veces COMO se cum- 
pla la condición escrita en 
la sentencia ++while. 

Veamos cómo funciona 


los peldaños de una escalera 
(del tipo que sea), un castillo 
de naipes, los libros de una 
estantería, etc. Programas 
como «Rhino» y «MAX» tienen opcio- 


) 


nes para colocar arrays de objetos en 
formaciones cuadradas, circulares o de 
manera que sigan un patch, pero hay 
algunas limitaciones como la posibili- 
dad de crear variaciones particulares en 
cada objeto del grupo. (Nota: esto no 
es del todo exacto. Tenemos entendido 


que existe un Ipas para «3D Studio» 
que permite hacer lo mismo y se dice 
que el lenguaje escénico de la versión 
2.5 de «MAX» permite hacer cosas in- 


object(galerial_3x3y) 


creíbles en este y otros apartados). 
Pues bien, en «POV» podemos crear 
cualquier escena de este tipo si com- 
prendemnos bien cómo debe emplearse 
thwhile. Esta sentencia funciona prácti- 
camente igual que sus equivalentes en 
lenguajes de programación como C, 
aunque la sintaxis es algo diferente. Pa- 
ra emplear +twhile tendremos que esta- 
blecer una condición que definiremos 
dentro de los paréntesis que siguen a la 
sentencia. Luego escribiremos una lista 


Una prueba sin texturas de una de las escenas principales. 


esto con algo más de deta- 

lle. Examinad el código de 

la Figura 1. En ella tene- 

mos dos ejemplos de bu- 
cles simples. En el ejemplo A la prime- 
ra sentencia es una declaración por la 
cual se otorga al identificador o varia- 
ble nz el valor 0. (Nota: si no recordáis 
cómo funcionaba Hdeclare, echad un 
vistazo al número 17). La siguiente 
sentencia es la instrucción +twhile y su 
condición puede leerse como “mientras 
nz sea menor que 40”. Las tres senten- 
cias siguientes componen el cuerpo del 
bucle y se ejecutarán una y otra vez 
hasta que nz sea igual al valor 40. en 
cuyo momento «POV» continuará pro- 
cesando las sentencias escritas después 
del Htend. Veamos esto paso a paso: la 
primera sentencia del cuerpo del bucle 
crea el objeto “Bcolum150_300s1” 
(que supuestamente ha sido definido en 
líneas anteriores). Este objeto se creará 
en la posición <0,0,0> porque —por 
ahora— nz vale cero. La siguiente sen- 
tencia creará otro objeto del mismo ti- 
po en la posición <450,0,0> (porque nz 
sigue valiendo cero). Después nz su- 
mará 1 a su valor anterior y al llegar el 
parser de «POV» (ver número 16) a la 
sentencia Hend, esta le hará cerrar el 
bucle y retornar al Htwhile para volver a 
considerar la condición. Entonces se 
volverán a procesar las dos primeras 


sentencias del cuerpo del bucle y se 
crearán dos nuevos objetos, aunque es- 
ta vez, como nz vale 1, los objetos se 
crearán en las posiciones <0.0,150> y 
<450,0,150>. (Tomad nota en cada 
ejemplo de la forma en que se emplean 
las transformaciones para situar espa- 
cialmente cada objeto creado por Hwhi- 
le). Al ejecutarse la tercera sentencia, 
nz pasará a valer 2 y al llegar al Htend el 
parser volverá a estudiar la condición 
de la sentencia ttwhile. Esto su- 
cederá una y otra vez hasta que 
nz valga 40 en cuyo momento 
la condición dejará de cumplir- 
se y el parser abandonará el bu- 
cle para comenzar a estudiar 
las sentencias que sigan al 
ttend. 

En este ejemplo, el bucle 
nos servirá para crear 80 obje- 
tos “Bcolum150_300s1”. Na- 
turalmente, también podríamos 
haber escrito manualmente las 
declaraciones de los 80 obje- 
tos, pero esto, sabiendo utilizar 
twhile, sería una estupidez. 
Además, en caso de haber co- 
metido un error de posiciona- 
miento o de otro tipo, será mu- 
cho más fácil corregir las pocas 
sentencias que forman el bucle 
que todas las líneas erróneas 
escritas manualmente. Tam- 
bién, de igual manera. nos resultaría 
sencillo alterar el bucle para crear cien- 
tos o miles de objetos en lugar de sólo 
80, ya que bastaría con cambiar la con- 
dición del bucle. 

Por otro lado, hemos de tener cuida- 
do con la condición escrita dentro del 
Hwhile y con las variables implicadas. 
Supongamos que hubiésemos olvidado 

incluir la sentencia Heclare nz=0z+1. 


En este caso nz seguiría valiendo siem- 
pre cero, sin importar cuántas pasadas 
se hiciesen, con lo cual el compilador 
de «POV» quedaría encerrado dentro 
de un bucle sin fin. ¿Sin fin? Bueno la 
verdad es que no. Hay que recordar que 
en este ejemplo estamos creando dos 
objetos en cada nueva pasada del bu- 
cle. Estos objetos ocupan una cantidad 
determinada de memoria (por pequeña 
que sea) y esto quiere decir que tarde o 


Prueba para portada, 


temprano «POV» nos soltaría un men- 
saje de memoria insuficiente y deten- 
dría la compilación sin haber renderi- 
zado ni una sola línea. (Por otro lado, 
como en el caso comentado nz siempre 
valdrá cero, lo que sucederá es que se 
irán creando pares de objetos, siempre 
en las mismas posiciones iniciales. Por 
tanto, si pudiéramos interrumpir el par- 
sing y ver los objetos creados, sólo ve- 


ríamos 2, aunque realmente se habrían 
creado cientos o quizá miles de ellos en 
la mismas posiciones). 

También podríamos cometer errores 
de otro tipo. Las sentencias de progra- 
mación como +twhile son sencillas de 
comprender pero pueden provocar ver- 
daderos desastres por culpa de peque- 
ños despistes. Si hubiésemos olvidado 
escribir +declare nz=0 antes del bucle y 
hubiésemos empleado a esta variable 
en bucles o cálculos anteriores, 
podría suceder muy bien que nz 
llegase al bucle con un valor 
superior a 40, con lo cual —co- 
mo la condición se estudia an- 
tes de realizar una sola pasada— 
no se realizaría pasada alguna 
ni se crearía ningún objeto. 
Ahora consideremos otra cues- 
tión. Con el ejemplo comenta- 
do crearemos un grupo deter- 
minado de objetos en la escena. 
Ahora bien, ¿qué sucede si de- 
seamos crear otro grupo de ob- 
jetos igual en otra posición? 
Supongamos que hemos utili- 
zado un bucle para crear los 
100 peldaños de una escalera y 
que hemos de crear varias esca- 
leras de este tipo en un edificio, 
Aunque nos hayamos ahorrado 
la escritura manual de los 100 
peldaños resultaría tedioso es- 
cribir el mismo bucle ++while una vez 
para cada escalera a crear (alterando 
únicamente los valores de posición de 
los objetos en cada caso). En lugar de 
esto sería mucho más práctico hacer al- 
go como lo que podéis ver en el ejem- 
plo B de la Figura 1. En dicho ejemplo 
se ha declarado una unión de objetos 
(ver número 17) y se ha escrito el mis- 
mo bucle +twhile de antes dentro de di- 


cha unión. De esta forma, podremos 
crear al grupo de objetos de la unión 
tantas veces como queramos en el es- 
pacio de «POV>». Para ello simplemen- 
te invocaremos a la unión dentro de una 
sentencia object, tal como puede verse 
en la última línea del ejemplo. Y para 
situar a cada copia del grupo en una po- 
sición diferente, únicamente tendremos 
que escribir una orden translate apro- 
piada dentro de cada sentencia object. 
Quizá convenga recordar que con ffde- 
clare los objetos sólo se están creando 
en la memoria de «<POV». Únicamente 


Figura 2: “este ejemplo de fwhile no funcionará correctamente” 


[ESCALERAS 
tideclare peldanno=union( 
object[Bsuelo100_100d1 ] 


object[Bsuelo100_100d2 translate<100,0,0>] 
object[Bsuelo100_100d1 translate<200,0,0>] 


] 


Hideclare tramo_escalera=union( 
tideclare npel=0 
while (npel<nmaxpel) 


object(peldanno translate<0,-20*npel,-28*npel>] 


tideclare npel=npel+1 
Htend 
J 


itdeclare nmaxpel=20 


Taller 


object[tramo_escalera translate<400,500, 1000>) 


tideclare nmaxpel=40 


object (tramo_escalera translate<1400,500,2000>) 


aparecerán en el pov-espacio cuando 
los objetos declarados sean referencia- 
dos con object. También conviene que 
recordéis que los desplazamientos pro- 
vocados por translate son sumas que se 
añaden a las posiciones anteriores de 
los objetos. 

Por último, consideremos otro caso 
más. Siguiendo con el ejemplo anterior 
supongamos que en nuestro edificio 
hay muchas escaleras del mismo tipo 
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pero que puede haber un número dife- 
rente de peldaños en cada escalera. En 
este caso quizá podríais sentir la tenta- 
ción de escribir algo parecido al trozo 
de código de la Figura 2. 

En este ejemplo hemos definido al 
objeto peldanno (para «POV» el carác- 
ter de la eñe es ilegal) como una unión 
de 3 objetos; cada peldaño está com- 
puesto por 3 piedras. Posteriormente, 
este objeto es referenciado desde den- 
tro de la siguiente unión, con la que 
construiremos la escalera, lo que es to- 
talmente correcto. En el ejemplo inten- 
tamos crear dos esca- 
leras, una de 20 
peldaños y otra de 40. 
Para ello asignamos 
un valor a la variable 
que establece el lími- 
te del contador de 
peldaños y luego in- 
vocamos a tramo_es- 
calera. Sin embargo, 
esto no funcionará. 

Si la variable nmax- 
pel no ha sido decla- 
rada antes de que el 
parser de «POV» lle- 
gue al +twhile, enton- 
ces aparecerá un 
error diciendo que 
esa variable no exis- 
te, aunque se la declare unas líneas más 
abajo. Y si damos un valor de, por 
ejemplo, 30 a nmaxpel, entonces las es- 
caleras serán siempre de 30 peldaños, 
independientemente del valor que asig- 
nemos más adelante a nmaxpel antes 
de cada invocación a tramo_escalera. 
Esto sucede porque el parser de «POV» 
sólo procesa una vez la declaración de 
tramo_escalera y por ello cada invoca- 
ción a esta unión siempre creará el mis- 


Otra prueba con 
iluminación de las 


escaleras. 


mo número de objetos. 

Sin embargo, existe una solución: si 
sacamos del fichero toda la declaración 
de tramo_escalera y la almacenamos en 
otro archivo que sea leído y procesado 
nuevamente, cada vez que queramos 
crear la escalera, la cosa funcionará. 
Con este sistema tendríamos que crear 
cada escalera escribiendo algo similar a 
lo que puede verse en la Figura 3. 

En esta figura hay trozos de código 
de dos archivos diferentes. Por un lado 
tenemos el bucle +twhile que creará la 
escalera y por otro las sentencias object 
dentro de las que hemos escrito los in- 
cludes. Cuando el parser de «POV» ha- 
lle el primer ttinclude (número 17 de 
Rendermanía) se cargará y procesará el 
archivo escalera.inc donde hemos es- 
crito el bucle. Como nmaxpel ha sido 
declarada antes del while guardado en 
el archivo que se va a leer, no se pro- 
ducirá ningún error y, en el primer ca- 
so, se creará una escalera de 20 pelda- 
ños. Luego se asignará a nmaxpel el 
valor 40 y volverá a leerse y a proce- 
sarse al fichero escalera.inc, con lo que 
se creará una nueva escalera de 40 pel- 
daños. Esto lo conocemos con el nom- 
bre de pov-macro (aunque otros la lla- 
man una pov-función). Realmente, y 
tal como lo ve «POV», esto es equiva- 
lente a escribir dos veces el bucle H+whi- 
le pero para nosotros la cosa funcionará 


camente bastante simple pero resulta 
muy adecuado para experimentar con 
el funcionamiento de las sentencias de 
programación, ya que todo —las pare- 
des, los suelos, las escaleras, los puen- 
tes, etc.— ha sido creado empleando bu- 
cles para situar las docenas o cientos de 
objetos simples que componen cada es- 
tructura. Además, los interiores resul- 


figura 3: “este ejemplo de f+while sí funcionará correctamente” 


lleste trozo de código es el archivo escalera.inc 
union[ 

tideclare npel=0 

Hwhile (npel<nmaxpel) 


object[ peldanno translate<0,-20*npel,-28*npel>)] 


tideclare npel=npel+1 
ttend 
) 


llel siguiente código está incluido dentro del archivo escénico con que se invoca a POV. 
El bucle ttwhile //está en otro archivo llamado escalera.imc 


(que sólo almacena ese trozo de codigo) 
tideclare nmaxpel=20 


figura 4: “ejemplo de bucle 


estará formada por 20*10 bloques de 
este tipo. Desde luego escribir a mano 
las 200 sentencias object para situar ca- 
da bloque de suelo es algo impensable. 
¿Qué haremos pues? ¿Utilizar 10 bu- 
cles ttwhile como los ya vistos? 

Pues no. Existe una forma más corta y 
simple de generar los bloques de este sue- 
lo. Examinad el código de la Figura 4. 

En este ejemplo declaramos una 
unión que emplea dos sentencias Htwhi- 
le para crear los 200 bloques del suelo. 
El primer bucle es el más externo y con- 
trola el número de bloques de profun- 
didad que han de crearse en el eje Z. (El 
cuerpo de sentencias de este bucle son 
todas las que se hallan comprendidas 
entre su Htwhile y el Hend más externo). 
Veamos cómo funciona esto: el parser 
de «POV>» comienza a procesar lineal- 

mente una sentencia 
tras otra. Al llegar a 


object (*Hinclude”escalera.inc” translate<400,500,1000>) Hwhile anidado? la sentencia object se 
fideclare nmaxpel=40 ld prner ajo 
e translate<1400,500.2000>) US a ( Coro la EUÍS está 
Hwhileinz<10) declarada”, sólo se 

Hideclare nx=0 crea el modelo en me- 

tal como lo hace una función de C. taban adecua- +while(nx<20) moria) en las coorde- 


object [Bsuelo200_200d1 


Si queremos crear 40 escaleras en 
distintas posiciones bastará con invocar 
40 veces a la pov-macro, aunque podría 
ocurrir que pudiéramos incluir las in- 
vocaciones dentro de un nuevo bucle 
ttwhile. lo que nos permitiría ahorrar 
aún más líneas de código. 


Bucles anidados 

Por último vamos a hablar de la ani- 
dación de bucles. En las escenas del 
presente número hemos utilizado un 
conjunto de objetos muy simple —blo- 
ques de piedra de pared y suelo, pelda- 
ños, etc.— para construir la arquitectura 
del Vormiguero. El resultado es gráfi- 


dos para hacer 
pruebas de ra- 


diosidad. Hend 
El suelo de E a 
'end 
una sala, por ) 
ejemplo, puede 


servirnos para explicar el asunto de los 
bucles anidados. En estas escenas tanto 
los suelos como los techos están for- 
mados por una matriz de bloques sim- 
ples. En los suelos, uno de los objetos 
más utilizados es un bloque de 2 me- 
tros de ancho (eje X) por 2 de profun- 
didad (eje Z) y medio metro de altura 
(eje Y). Así, el suelo de una sala de 40 
metros de ancho por 20 de profundidad 


nadas determinadas 


translate<nx*200, O, nz*200>) 
Hideclare nx=nx+1 


por nx y nz. Luego se 
incrementa nx y, al 
llegar al Htend, se re- 
torna al último Hwhi- 
le leído. 
Hay que comprender que las senten- 
cias ttwhile y Htend se emparejan como 
los paréntesis de una fórmula. El ttend 
en el que nos estamos fijando pertene- 
cerá siempre al último +while “libre” 
que se se haya escrito antes del men- 
cionado ttend. Tened la costumbre de 
utilizar la tabulación para visualizar 
mejor las correspondencias ttwhile- 
ftend. 
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figura 5: “formatos de ¿if y ttelse” 


[primer caso 
HHif (condición) 


sentencias que se compilan si la condición se cumple 


Htend //fin del Hif 


//segundo caso 
HHf (condición) 


sentencias que se compilan si la condición se cumple 


Helse 


sentencias que se compilan si la condición no se cumple 


ttend //fin del Hif 


En definitiva, el ttend hallado hará 
que el parser retorne a considerar nue- 
vamente la condición del segundo 
Hwhile del ejemplo (al que llamamos 
el “más interno”). Como nx sigue sien- 
do menor que 20 (ahora vale 1), se cre- 
ará un nuevo objeto. Este proceso se re- 
petirá hasta completar 20 pasadas en 
cuyo momento, al haber llegado nx a 
20, la condición dejará de cumplirse y 
el compilador pasará a procesar la sen- 
tencia que sigue al Htend. Nz pasará, en- 
tonces, a valer 1 y el siguiente ttend ha- 
rá que el parser retorne al Htwhile que 
corresponde a dicho Hend (y que en es- 
te caso es el primero y el más externo). 
Como nz vale 1 volverán a procesarse 
todas las sentencias comprendidas den- 
tro del bucle externo y nx volverá a to- 
mar el valor O, con lo que todo el bucle 
interno volverá a ejecutarse. 

Resumiendo, por cada pasada del 
bucle más externo, el que le sigue se 
ejecutará tantas veces como determine 
su condición (en este caso 20 veces). 
En cada nueva pasada del bucle exter- 
no, nz se incrementa en 1 por lo que los 
20 objetos que se crean dentro del bu- 
cle más interno se sitúan 200 unidades 
más lejos en el eje Z que los 20 objetos 
de la pasada anterior; echad un vistazo 
a la fórmula. 


Taller Virtual 


Nota: en los ficheros que 
definen los objetos del 
vormiguero, 100 unida- 


des equivalen a un metro. 

En este ejemplo hemos 
empleado un bucle doble 
pero el nivel de anida- 
ción podría ser mayor. 
Podríamos emplear un 
tercer bucle dentro del 
segundo para que los ob- 
jetos se creasen en los 
tres ejes. En realidad, en «POV» será 
muy raro que haya que emplear bucles 
de profundidad superior a 3 pero, se- 
gún el manual, podemos llegar a escri- 
bir un superbucle anidado con 200 
Htwhile de profundidad. 


HHf y Helse 


A continuación veremos cómo fun- 
cionan las construcciones +Hf y Helse. 
Los formatos más usuales de estas sen- 


figura 6: 
“ejemplos de uso de Hif y Helse” 


1lejemplo A 
tideclare yuyu=10 


tf (yuyu=452*75) 
object[bloquel ] 
Htend 
llejemplo B 
if (yuyu=10) 
object! bloque2) 
else 
object(bloque3] 
Hend 
object[bloque4] 
Hlejemplo € 
fideclare reyuyu=yuyu+10 
if (yuyu=10) 
Hif (reyuyu=20) 
object(bloque5 ] 
Htend 
Helse 
object[bloque6] 
Hend 


AM 


tencias los podéis ver en la q s 


El uso de +Hf es aún más simple que 
el de ttwhile y el caso más frecuente es 
el del primer ejemplo. Todas las sen- 
tencias que quedan entre el H1f y su 
ttend forman parte del cuerpo de la 
sentencia condicional y serán compi- 
ladas si la condición del +H1f se cumple. 
(Estas sentencias pueden leerse como 
“si se cumple la condición tal, enton- 
ces compilar las sentencias del Ht1f). En 
caso contrario, el parser las ignorará y 
pasará a compilar las que haya después 
del ttend. 

En cuanto al formato del segundo 
caso, funciona exactamente igual que 
el caso anterior salvo por el hecho de 
que las sentencias que siguen al +felse 
se compilarán sólo si la condición no 
es cierta. En ambos casos. tanto si se 
compilan las sentencias atadas al +Hif 


Añadimos la luz 
de las escaleras. 


figura 7: “símbolos utilizados en las condiciones de Hif y Hwhile” 


yuyu llega al 
Hif valiendo 
10, la condi- 


(A=B) La condición se cumple si A es igual a B 

(A!=B) e *” si Aes diferente a B ción no se 

(A>B) sn “” si A es mayor que B cumple y el 

(A>=B) 5) > si A es mayor o ¡gual que B objeto blo- 

(A<B) E “7 si A es menor que B quel no se 

(A<=B) Se “> si A es menor o igual que B crea. En el 
ejemplo B 


(condición cumplida) como las atadas 
al Helse (condición incumplida), el par- 
ser de «POV>» continuará después con 
las sentencias que siguen al ttend. 

La sentencia telse está asociada 
siempre a un H1f y el Hend cierra la 
construcción definida por ambas sen- 
tencias o por un Hif solitario. Ahora 
echad un vistazo a los ejemplos de có- 
digo de la Figura 6. 

En el ejemplo A, como la variable 


se Crean los 
objetos bloque2 y bloque4 y en el 
ejemplo € se crea el objeto bloque 5. 
Fijaos en la estructura del ejemplo C. 
Al igual que sucedía con H+while, pode- 
mos encadenar sentencias *Hif y crear es- 
tructuras lógicas bastante complejas. 


Condiciones 

Tanto ftif como while emplean sím- 
bolos para calcular si las condiciones 
se cumplen o no. Intentad memorizar 
los símbolos de la Figura 7 

La verdad es que «POV>» calcula si la 
condición se cumple o no tal y como lo 
hace el lenguaje C: es decir, se calcula la 
expresión incluida dentro de los parén- 
tesis y si obtenemos un resultado de O 
se entiende que la condición es falsa y 
no debe cumplirse. Cualquier valor di- 
ferente a O será interpretado como cierto 
pero hay que recordar que los valores 
extremadamente pequeños (de le-10 o 
menos) pueden ser considerados por 


figura 8: “ejemplos de condiciones válidas para +Hif y ftwhile” 


(A=B 8 C>B) 
((ABB €: B<=10) | C>A) cs 


Ces menor que A 


Recordad que —-de nuevo— las senten- 
cias ttend van ligadas a los +fifs siguien- 
do la regla de los paréntesis (a cada pa- 
réntesis de una orientación corresponde 
otro de orientación distinta e idéntica 
profundidad). Aunque el funciona- 
miento de +tif es muy simple, es muy 
fácil confundirse si tenemos muchos 
Hifs y twhile encadenados. Intentad, 
pues, utilizar la tabulación para no des- 
pistaros y, si es preciso, incluid comen- 
tarios que indiquen a que *twhile o +if 
pertenece cada end. Es importante te- 
ner en cuenta que debe haber siempre 
un ffend para cerrar los bloques H+while 
o Hhf: Si nos despistamos y ponemos un 
ftend de más o de menos habrá proble- 
mas; tal y como sucede si nos equivo- 
camos con el número de paréntesis de 
una operación. 


La condición se cumple si A es igual a B y Ces mayor que B 


si A es igual a B y B es menor o igual que 10 o bien si 


«POV>» como 0. Por último, la condi- 
ción a cumplir puede ser bastante más 
compleja de lo que se indica en la Fi- 
gura 7 y así podemos escribir condicio- 
nes tales como las que pueden verse en 
la Figura 8. 

El símbolo $ debe leerse como “y” 
y sirve para forzar el cumplimiento de 
dos o más condiciones. En el segundo 
ejemplo hemos utilizado el símbolo | 
que debe leerse como “o” y que permi- 
te que las sentencias encadenadas se 
compilen si se cumple una condición o 
bien otra. (Notad que en el segundo 
ejemplo hay dos condiciones, no tres). 
Realizad vuestros propios experimen- 
tos con las condiciones de +tif y ttwhile 
y recordad que éstas funcionan de ma- 
nera prácticamente idéntica a la de sus 
sentencias hermanas de C y C++. 


Funciona la radiosidad de PO 


En el número anterior ya comentamos 
que los algoritmos de radiosidad son, por 
ahora, los únicos que pueden 


simular aceptablemente la luz difusa, 


y que «POV» incluye una opción de radiosidad. 


Pues bien, en este número vamos a 


estudiar la radiosidad que ofrece «POV», 


ntes de comenzar a 
estudiar las opciones 
que incluye la radio- 
sidad de «POV», 
vamos a recordar 
las diferencias que 
presentan los algoritmos de radiosidad 
con respecto a los algoritmos scanline 
tradicionales o los de trazado de rayos. 


Modelos de iluminación y 
algoritmos de sombreado 
Llamaremos algoritmo de sombrea- 
do a cualquier método por el que se dé 
color a las superficies de los objetos 
existentes en los universos 3D genera- 
dos en juegos. simulaciones O 
en programas de generación de 
imagen sintética como «3D 
Studio» o «POV». Existen mu- 
chos algoritmos de sombreado 
y cada uno presenta distintas 
ventajas e inconvenientes. To- 
dos ellos se apoyan en diferen- 
tes modelos luminosos que no 
son sino simplificaciones que 
intentan simular el funciona- 
miento de la luz del universo 
real con un costo de tiempo ra- 
zonable. Algunos de ellos fue- 
ron ideados pensando en limi- 
taciones de cálculo que los 
ordenadores actuales han deja- 
do muy atrás y que ya apenas 
se utilizan (¿quién recuerda el 
método de intensidad constan- 
te 0 flat?). Otros, en cambio, 
requieren aún tanto cálculo que 
apenas son prácticos. Pero no 
vamos a ponernos ahora a ex- 


se 


o nr 


La escena de ejemplo de Dan Farmer generada 
con radlosidad. 


plicar cómo funciona el sombreado 
Phong o en qué se basan los modelos 
luminosos de Whitted. Hall y otros in- 
vestigadores. En lugar de esto vamos a 
Intentar establecer una sencilla clasifi- 
cación para estos algoritmos. 

Por un lado, tenemos los llamados 
algoritmos scanline o de línea de ras- 
treo, luego están los de trazado de ra- 
yos y por último se encuentran los mé- 
todos que emplean radiosidad. 

En los algoritmos scanline el método 
empleado consiste en hacer un barrido 
de la imagen de arriba a abajo. Previa- 
mente podemos haber empleado cual- 
quier algoritmo para determinar las su- 
perficies visibles pero no es infrecuente 
que en estos casos se utilice también el 
algoritmo de eliminación de superficies 
ocultas que lleva también el nombre de 
línea de rastreo. Ciñéndonos a lo bási- 
co, cada pixel de las superficies visibles 
será coloreado atendiendo al ángulo 
que presenta con respecto a las fuentes 
de luz que lo iluminan. También sue- 
len tenerse en cuenta otros factores co- 
mo los colores de los objetos y de las 
fuentes, la atenuación de la luz con la 
distancia, etc. Por último, conviene re- 
señar que casi todos los algoritmos de 
este tipo no aplican el modelo lumino- 
so completo (es decir, todas las fórmu- 


las) en cada punto, sino que suelen rea- 
lizarse interpolaciones con el color de 
los puntos (Goraud) o con las norma- 
les (Phong) para ahorrar tiempo. 

En el trazado de rayos, en cambio, el 
sistema es muy diferente y mucho más 
complicado. Para generar una escena el 
programa lanzará rayos desde la teórica 
posición del observador. Se trazará. al 
menos. un rayo para cada pixel de la 
escena y cada uno será seguido para 
comprobar si choca con la superficie de 
algún objeto. Esto implica ya muchos 
cálculos, pues no es tan fácil determi- 
nar cuándo un rayo ha chocado o no 
con superficies de forma compleja. Por 
ello suelen emplearse métodos como el 
de las cajas bounding para minimizar 
los cálculos. En este método cada obje- 
to es encerrado dentro de una caja invi- 
sible que tiene sus mismas dimensio- 
nes máximas. Esto se hace así porque a 
menudo es mucho más rápido compa- 
rar choques con cajas que con los obje- 
tos que éstas contienen. Además, si el 
número de objetos es muy grande, en- 
tonces puede establecerse un nivel de 
Jerarquía mayor para ahorrar tiempo. 

En el caso de nuestras escenas de ba- 
tallas, por ejemplo, «POV>» podría estar 
empleando una caja para cada guerre- 
ro. El rayo comprobaría el posible cho- 


La misma escena con trazado de rayos. 


que con respecto a cada cubo-guerrero 
y luego, cuando se hubiese determina- 
do el choque con el cubo contenedor de 
un soldado en particular, entonces se 
harían comprobaciones de posición 
con las cajas contenedoras “de menor 
Jerarquía” de los objetos componentes 
(manos. antebrazos, etc.) de ese solda- 
do en particular. Sólo cuando se hu- 
biese llegado a determinar el choque 
del rayo con una de estas cajas “de 
menor jerarquía” procedería el progra- 
ma a realizar los lentos cálculos rayo- 
superficie con el objeto contenido den- 
tro de la caja en cuestión: esto ahorra 
numerosos cálculos. 

Una vez que el rayo del observador 
ha chocado con una superficie se lan- 
zan los llamados “rayos de sombra” 
desde el punto del choque. Se enviará 
un rayo de sombra por cada fuente de 
luz que exista en la escena y cada rayo 
se dirigirá en línea recta hacia una 
fuente concreta para comprobar si el 
camino hacia dicha fuente está despe- 
jado o no. Aquí de nuevo se gana 
tiempo con el sistema de las cajas con- 
tenedoras. Con ello se comprobará 
qué fuentes iluminan al punto de cho- 
que en cuestión y las intensidades se 
sumarán para determinar el culor del 
punto. La cosa puede complicarse mu- 
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CómoO... 


cho si estamos empleando áreas de luz. 
La cosa se complica aún más por el he- 
cho de que el trazado de rayos también 
trata la reflexión y la refracción de la 
luz. Así, cuando un rayo primario uno 
de los lanzados originalmente— choca 
con una superficie, se lanza un nuevo 
rayo, al que denominaremos reflejado. 
Este nuevo rayo parte del punto de cho- 
que siguiendo una trayectoria especu- 
lar; lo que significa que abandonará la 
superficie impactada con el mismo án- 
gulo con que el rayo primario ha llega- 
do a ella. De esta manera, el programa 
seguirá al nuevo rayo para comprobar 
si choca con una nueva superficie. Si se 
da este caso se lanzarán rayos de som- 
bra desde el nuevo punto de choque pa- 
ra comprobar si las fuentes lo iluminan 
y la intensidad con que lo hacen. El to- 
no de color de este punto se sumará al 
del primer punto de choque del que 
partió el rayo reflejado. ¡Pero esto no 
es todo! También se lanzará un nuevo 
rayo reflejado desde el segundo punto 
de choque y esto continuará hasta lle- 


gar al valor máximo de recursión que 
hayamos estipulado para el programa. 
En «POV». por defecto. es de 5. aun- 
que podemos cambiar este valor con la 
variable max_trace_level, dentro de la 
sentencia global_settings. 

Pero todo esto no es más que una 
simplificación. Ni siquiera hemos ha- 
blado de los rayos transmitidos que se 
lanzan cuando las superficies impacta- 
das son total o parcialmente transpa- 
rentes, pero lo dicho es suficiente para 
comprender de dónde toma su nombre 
el trazado de rayos y para saber por 
qué se consiguen imágenes más realis- 
tas con el ray-tracing que con los mé- 
todos scanline. Es cierto que también 
pueden conseguirse reflexiones con es- 
tos métodos, pero normalmente hay 
que indicarlo al programa y al hacerlo 
estaremos perdiendo parte de la única 
ventaja que tiene el rastreo de línea so- 
bre el trazado de rayos: el menor tiem- 
po de cálculo. 

¿Y qué es la radiosidad? Pues es un 
modelo de iluminación que se basa en 


Cuando el valor de count es demaelado bajo la radlosidad 


empieza a perder calidad. 
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la termodinámica. Los métodos basa- 
dos en la radiosidad estudian la distri- 
bución de energía en las superficies de 
ambientes cerrados. En estos métodos 
todas las superficies pueden ser fuen- 
tes emisoras de luz u objetos reflec- 
tores o ambas cosas. De esta manera, 
calculando la cantidad de energía ra- 


zar rayos de la forma antes descr 


La radiosidad de POV 
Por detecto, la radiosidad de «POV» j 

está desconectada. Esto se debe a que 

el algoritmo empleado es experimental 

y quizá sea cambiado en el futuro (aun- 

que parece que todo sigue igual en la 

nueva versión 3.1). Naturalmente. esto 

implica que los archivos de escena que 

se rendericen ahora con radiosidad 


pueden producir imágenes diferentes 
en futuras versiones de «POV». 

El algoritmo de radiosidad imple- 
mentado en «POV» está basado en el 
método de Greg Ward cuyos detalles 
exactos de funcionamiento todavía nos 
son ¡stanocidos: aa as vuestros 


blanco y suelo a cuadro 
les. Los únicos objetos son. 
blanca situada cerca de la pa: 
una especie de ladrillo amarillo 
cado cerca de la pared azul. Pero, ¿dond 
de están los efectos dE la radi AN 


hemos de incorporar el com; 
a la línea de órdenes con 
mos al programa. Ant es, 

editad el archi 


nuestro primer experi- 
marca “17” de comenta- 
rio de esta última línea y de la que asigna 
a Rad_Quality el valor Radiosity_Nor- 
mal. Después, invocad a «POV» con el 
comando +Qr y no olvidéis dar otro 
nombre al fichero de salida para poder 
comparar la imagen resultante con la 
anterior. Una vez que la escena haya si- 
do renderizada, comparadla con la an- 


E 


Ejemplo usando el valor de 800 para count. 


— 
terior. Al principio ambas imágenes os 
rán casi iguales pero los cam- 
bios. aunque sutiles, se harán evidentes 
inmediatamente. 
en la esfera bl 


ijaos, por ejemplo, 
ca: en la escena gene- 
lado pegado a la 
tiene un leve tono rojizo 


rada con radiosidad 


e queda frente a la 
s, hay también otros 


s estos cambios se deben a las 
reflexiones difusas que «POV>» sólo 
calcula cuándo se activa la opción de 
radiosidad. Como recordaréis, en el nú- 
mero anterior, llamábamos luz difusa o 
ambiental a la que se producía como 
consecuencia de las múltiples reflexio- 
nes de los rayos de luz con los objetos. 
En el mundo real. los rayos de luz cho- 
can contra los objetos y rebotan una y 
otra vez. Este efecto es simulado en los 
métodos de radiosidad lanzando rayos 
entre las superficies para determinar el 
intercambio de energía radiante en el 


espectro visible. Esto significa dos co- 
sas: la primera que habrá iluminación 
en zonas que no resultarían iluminadas 
con el simple trazado de rayos, y la se- 
gunda, que el color de la luz que radian 
las superficies se sumará a la ilumina- 
ción directa proporcionada por las 
fuentes de luz. Es esta última conse- 
cuencia lo que hace que la esfera reciba 
iluminación indirecta roja y azul de las 
paredes. 


Algunas pruebas de 
radiosidad 

Pero hagamos más pruebas. En 
«POV» podemos controlar ciertos as- 
pectos de la radiosidad con una serie de 
sentencias que deben ir incluidas entre 
las llaves de la instrucción “Radiosity”. 
A su vez, esta sentencia figura entre las 
que pueden escribirse dentro de la ins- 
trucción global_settings, utilizada para 
ajustar ciertos parámetros en la gene- 
ración de la imagen. como el factor 
gamma. el nivel máximo de recursión 
de los rayos reflejados a lanzar, etc. 
Así, el formato general de esta senten- 
cia lo podéis ver en la Figura 1 (página 
siguiente). 

Si queréis ver algunas pruebas he- 
chas con valores predeterminados edi- 
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Figural: “Formato de la sentencia radiosity 
utilizada para ajustar la opción de radiosidad” 


global_settings [ 


/[Nota: no es preciso colocar todas las sentencias 


radiosity [ 

brightness FLOAT 

count INTEGER 
distance_maximum FLOAT 
error_bound FLOAT 
gray_threshold FLOAT 
low_error_factor FLOAT 
minimum_reuse FLOAT 
nearest_count INTEGER 
recursion_limit INTEGER 


tad el fichero rad_def.inc situado en el 
directorio include de la instalación de 
«POV». Este archivo es “incluido” por 
rad2.pov, tiene guardados varios ejem- 
plos para la sentencia radiosity, y eje- 
cutará uno u otro dependiendo del va- 
lor que activemos en rad2.pov para la 
variable Rad_Quality. Así, si activamos 
(quitando los caracteres de comentario) 
el valor Radiosity_Normal, se emplea- 
rán valores medios para la radiosidad. 
Con Radiosity_Fast obtendremos un 


Cómo... 


resultado más rápido pero con una 
calidad inferior, con Radiosity_Fi- 
nal obtendremos unos resultados de 
mucha más calidad (pero más len- 
tos), etc. 

La verdad es que, normalmente, 
los cambios producidos por las sen- 
tencias incluidas en el bloque ra- 
diosity son prácticamente imper- 
ceptibles, y por ello vamos a prestar 
atención sólo a algunas de ellas. 

Editad el fichero rad3.pov, donde 
hemos incluido un bloque glo- 
bal_settings para hacer nuestros 

propios experimentos, y preparaos pa- 
ra trastear. Nuestra primera prueba 
consistirá en cambiar el valor que sigue 
a la sentencia count por el valor 10. 
Renderizad el archivo y comparadlo 
con el anterior (que se renderizó con un 
count de 200). Como veréis, el render 
tardará mucho menos tiempo pero los 
resultados serán bastante inaceptables. 
El tono general de distribución de luz 
será tan correcto como en la prueba an- 
terior. pero los colores estarán dispues- 


Con gray_threshold a 0.10, la radiosidad gana color. 


tos a brochazos. Esto se debe a que el 
algoritmo de radiosidad lanza rayos 
desde cada punto con ángulos determi- 
nados para establecer la energía que re- 


cibe ese punto. 

Si el valor de count es muy bajo o si 
hay una gran diferencia de tamaño en- 
tre los objetos de la escena, entonces 
ésta no se calculará correctamente. Un 
valor de 200 será normalmente el ade- 
cuado para count pero si apreciáis un 
efecto parecido al de esta última prue- 
ba, probablemente tendréis que elevar 
este valor. También debéis procurar 
que las desigualdades de tamaño entre 
los modelos de la escena no sean exce- 
sivos. No es conveniente, por ejemplo, 
enfocar una manzana sobre el suelo de 
un patio de 40 metros cuadrados. ¿Por 
qué? Porque cuanto mayores sean las 
diferencias de tamaño entre los objetos 
de la escena, mayores serán los ángulos 
de los rayos “de radiosidad” que habrá 
que lanzar y mayor será la probabilidad 


Esto es lo que sucede empleand 


uy bajos para conut. 


de que la escena tenga fallos, al haber 
zonas que no reciban estos rayos. 

En teoría podemos corregir el pro- 
blema subiendo el valor de count, pero 
en la práctica el aumento de tiempo 
puede convertir esta opción en algo po- 
co práctico. (Nota: hace ya bastante 
tiempo tuvimos el mismo problema 
con «Raysmith», un programa de ra- 
diosidad creado por un autor español. 
En general, la falta de tiempo nos obli- 
gó a generar escenas con pocos rayos 
y por ello las imágenes tuvieron menos 
calidad de la que deberían haber teni- 
do). Aquí hay que decir que «POV» 
dispone de una sentencia que supues- 
tamente puede arreglar este problema 
sin necesidad de aumentar el valor de 
count. Se trata de distance _maximun. 
El valor que sigue a este parámetro está 
relacionado con el tamaño de la zona 
enfocada y de la distancia de la cámara 
ala misma. Sin embargo. reconocemos 
que aún no sabemos emplearla adecua- 


damente, por lo que tuvimos que dejar 
este valor a O y limitarsnos a trastear 
con el valor de count. 

Otra sentencia que afecta a la cali- 
dad de la escena es recursion_limit. que 
controla la recursión de los rayos. pero 
lo mejor será que dejéis su valora l a 
no ser que dispongáis de un Pentium 
VI a 3000 MHz. 

Por último, es interesante jugar con 
el valor de gray_threshold. En el uni- 
verso real, los millones de reflexiones 
de rayos que se producen entre superfi- 
cies de distinto color hacen que se pro- 
duzca una mezcla de color por la cual 
normalmente la luz ambiental tiende a 
tomar un tono gris. «POV» lo simula 
con el valor de este parámetro. 

Probad, por ejemplo, a bajar el valor 
de gray_threshold a 0.10 en nuestra es- 
cena experimental. Como veréis, los 
colores resultantes de la iluminación 
difusa serán mucho más vivos (podréis 
apreciarlo si os fijáis en los tonos rojos 


y azules de la esfera). Si, en cambio, 
probáis con un valor de 0.90 o mayor 
para este parámetro, entonces los tonos 
serán casi grises. 

En definitiva, un valor muy bajo de 
gray_threshold hará que la escena pa- 
rezca casi de dibujos animados, mien- 
tras que un valor próximo a 1 provo- 
cará que el color de la luz ambiental 
desaparezca. Es recomendable utili- 
zar valores de 0.35 a 0.65, según los 
casos. 


Sobre los experimentos 

Todos los experimentos iniciales se 
realizaron con el archivo de prueba 
rad2.pov. Sin embargo, también se lan- 
zaron algunas pruebas con los escena- 
rios de interiores que se crearon para el 
presente número. La idea inicial para 
estos escenarios era crear algo basado 
en la arquitectura del egipto de los fa- 
raones, pero esta idea acabó en la pa- 
pelera cuando el autor vió el magnífi- 
co mapa lkdm4 para «Quake 2» de 
likka Keranen. Este mapa estaba le- 
no de pasillos y salas muy sencillas 
construidas con muy pocos elementos 
que se repetían en suelos, techos y pa- 
redes. Sin embargo, a pesar de esta 
sencillez, el mapa resultaba precioso 
y sus estructuras resultaban, además, 
fáciles de reproducir con las senten- 
cias de programación. Por otra parte, 
dichas estructuras eran también idea- 
les para hacer pruebas de radiosidad. 

Nota: desgraciadamente, el segundo 
ordenador con el que esperábamos ha- 
cer estas pruebas, un Pentium IT a 266 
MHz, se estropeó y sólo pudimos con- 
tar con nuestro viejo Pentium a 150 
MHz. Por esta razón, no hemos podi- 
do dejar los escenarios tan bien como 
hubiésemos deseado. 
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POVRAY 3.1 


BA 
h 


¿Un lenguaje de programación? 


Aunque estaba previsto comenzar este mes con 


enay ho Ver dow documentation 


el especial de animación, hemos decidido 


retrasarlo por dos razones: el espacio que ha 


ocupado el artículo anterior y... por la salida de la 


beta de la próxima versión de «POV». 


Efectivamente, «POV 3.1» ya está disponible en http: //www.povray.org y 


trae algunas novedades que harán furor entre nuestros pov-adeptos. 


n más de una oca- : 
sión hemos comen- ; 
tado que la estructu- : 


ra del 
escénico de «POV» 


recuerda a la de un : 


lenguaje de programación y, en particu- 


lar, ala de C. Pues bien, parece que esta E 
semejanza ha aumentado en la nueva a 
versión 3.1 (y presumiblemente seguirá E 
haciéndolo en el futuro). La nueva beta E 


(que estará vigente hasta septiembre) in- 


corpora arrays, macros, funciones de : 


apertura, lectura y grabación de ficheros 


«POV». Sin duda, cualquier 
«POV» que domine € com 
que significan estos cambios 
bién hay algunas 
artado de las textu- 


16 Rendermanía 


lenguaje : 


ras, pero lo comentado arriba va a su- 
poner cambios revolucionarios entre los 
amantes de la infografía y la programa- 
ción. ¿Por qué? Bueno, para empezar 
las nuevas sentencias de lectura y gra- 
bación nos van a ser útiles para un mon- 
tón de cosas. Según el manual provisio- 
nal de «POV», las nuevas sentencias 
ttopen, tfread, write y tHclose fueron 
creadas como una ayuda para el aparta- 
do de animación (para pasar informa- 
ción al frame siguiente y cosas asf) pero 
lo cierto es que podrían ser empleadas 


E para los objetos. De esta manera, le- 
E yendo y procesando los datos de estos 
E arrays, podríamos crear escenas con 
a miles de objetos complejos y asegurar- 
, nos de que jamás habría superposición 
: espacial. Además, si estos arrays tuvie- 
sen datos relativos al terreno, quizá po- 
E dríamos crear animaciones de persona- 
E jes cuyos pasos se adaptasen al terreno. 


Otro avance es la implementación de 
macros. Con ellas parece ser que por fin 


¿tendremos algo muy parecido a las fun- 
¿ciones de C sin necesidad de sacar có- 


igo a otros ficheros, como hasta ahora. 


El Foro del Lector 


Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de Pemanía, o vía e-mail a rendermania.pomaniaO hobbypress.es 


El regreso del Mech 


En el foro de este mes, un 
buen porcentaje de los 
modelos enviados son 

mechs muy variados. 
Además, nuestra amiga 
Pamela volverá a honrarnos 
con su deliciosa presencia y 
también contaremos con 
otros interesantes trabajos, 
entre los que hay bicicletas, 
templos griegos, cuadros 
abstractos e incluso un 


huevo pov-ipas. 


ANGEL LANZA 5: 


De nuevo está con nosotros Jesús Angel lanza Salcines 


que nos envía una nueva página HTML donde volveremos a 


disfrutar de la compañía de la ya famosa Pamela. ¿Qué más 


se podría decir de esta maravillosa chica virtual de 7266 vér- 


tices? ¡No os perdáis estas fantásticas pam-escenas! 
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A y 


El Foro del Lector 


nos envía 


Nuestro amigo es otro recién llegado al 


mundillo de la imagen sintética. Sus primeras unas escenas hechas con «3D 


imágenes han sido modeladas con «Spatch» y Studio 4» entre las que se in- 
renderizadas desde «Imagine». Según afirma en cluye un mech de su inven- 


su carta, Josh no ha podido tirar los renders des- ción. Juan Luis adjunta su di- 


de «POV» porque no tiene este programa y tam- rección para intercambiar modelos y texturas con otros 
bién carece de conexión a Internet. ¿Que por rendermaníacos y amenaza con enviar sus próximas escenas a una 
qué no hemos publicado «POV»? Bueno, PC- resolución de 1600* 1200 (por favor. no excedas los 800*600 pixels). 
manía ha publicado este raytracer varias veces y En cuanto al envío de los modelos, creo que si hubieses empleado un 
tiene intención de volver a hacerlo pero lo cierto número cuatro veces menor de polígonos, el mech no hubiese perdi- 
es que el Povteam (sus creadores) aún no han do detalle; no te apures, el emplear un exceso de caras es una manía 
contestado nuestra última carta solicitando su muy corriente. Hasta la próxima. 


permiso para ello. Esperamos poder publicarlo 
muy pronto. En cuanto a tus otras preguntas: 
1) Las texturas procedurales de «POV» son. 


en mi opinión, mejores que las de «Imagine» nos envía algunas escenas realizadas con «Corel 
porque el primero posee más sentencias para Dream 3D» y pregunta si existen conversores para pasar los modelos de este 
crear texturas de este tipo que opciones tiene programa a otros formatos más convencionales con el fin de participar en al- 
«Imagine» para hacer lo propio. Además, la ca- guna de las próximas batallas. 
lidad del render de «POV» es superior. No sé nada de este programa ni de posibles conversores para él, aunque 
2) En el artículo de este mes dedicado a la apostaría a que debe tener una opción de exportación para el formato DXF y 
radiosidad se resumen las diferencias entre los eso es tudo cuanto necesitas para que podamos emplear tus modelos (aunque 
métodos scanline, y los de trazado de rayos y a veces los modelos grabados en este formato dan muchos problemas). Res- 
de radiosidad. pecto a lo que comen- tt TERRA IN UG. (97. 
3) ¿Los fallos más grandes de tu trabajo? tas, existe una versión 
Bueno, mas que de fallos yo hablaría del cami- recortada de «3D Stu- 
no que todavía te queda por recorrer. Tu primer dio», aunque PCmanía 
paso debería ser coger más soltura en el mode- por ahora no va a pu- 
lado, después te sería conveniente aprender a blicarla. Y te reco- 
ambientar mejor las escenas: la iluminación. miendo el libro «3D 


las texturas, la atmósfera, etc. Studio 4» de Anaya. 


otro viejo conoci- 
do nuestro, vuelve a estas páginas 
con tres magníficas escenas crea- 
das con «3D Studio», «Max», 


«Metaballs 2» y «Bryce 2» (al que 


“The Mechs 11” 


no conozco). Tu chica me ha gusta- 
do mucho (aunque hubiese preferido verla de cuerpo entero) y me ha impresionado el extraordinario rea- 


lismo del agua de metalsII (¿creada con «Bryce»?). En cuanto al envío de obras, preferimos que las en- 


viéis en formato JPG y a 800*600 pixels, aunque no es obligatorio. 

Por otro lado, Benyi ofrece a todos los rendermaníacos la posibilidad de publicar sus obras en Internet, en una exposición gratuita 
(leed su carta en el foro). Y por último, por lo que respecta al desafío entre mechs del que hablas, podéis utilizar las reglas explica- 
das en la última página de Rendermanía 18 —al menos hasta que alguien envíe sugerencias para mejorar dichas reglas—. Por supuesto 


espero esas animaciones tuyas , pero recuerda que preferimos que las animaciones —ya comprimidas— no excedan los 5 Megas. 


alias Narcosis, nos envía una magnífica bicicleta 
modelada y renderizada con «POV» y algunas preguntillas: 

1) Es cierto que algunos de los últimos artículos sobre «POV» son algo duros de 
digerir pero ello se debe más a la necesidad de resumir que a la complejidad de los 
mismos. Ten en cuenta que de «POV)» podría escribirse tranquilamente un libro de 
600 páginas sin necesidad de incluir paja dentro del mismo. 

2) Es muy raro que yo utilice más de dos fuentes de luz para una escena y real- 
mente esto es lo que mejor suele quedar si se consigue un buen contraste entre las 
zonas oscuras y las iluminadas. Si sitúas un exceso de luces lo único que conse- 
guirás será que toda la escena te quede empastada y sin tonos . ¡Pero la colocación 
de estas luces no es nada difícil! En general, lo más simple es tomar nota de la si- 


tuación de la cámara y dar las mismas coordenadas a una de las fuentes, sumando 


una pequeña variación posicional. 


3) La apariencia de las texturas depende no sólo de El mech enviado por 
las propiedades asignadas a las mismas sino también y creado con «3D Studio» tie- 


del color y número de las fuentes de luz. ¡No pongas ne probablemente el diseño más simpá- 


demasiadas, en tu bici has puesto 6 tico que hemos visto aquí (la escena 
cuando podrían haber bastado 2! donde su eriaturilla persigue al marine 
4) En cuanto a la diferencia entre espacial de Roberto Celorrio es muy di- 
las imágenes impresas y las equiva- vertida). Luis incluye, además, una carta 
lentes del CD. La verdad es que a explicando los detalles de modelado y 
veces algunas escenas llegan tan os- también al mismo modelo para que sea 
Curas que no hay más remedio que libremente uti- 
subirles el contraste o iluminarlas <A lizado por 
un poco para que resulten mínima- cualquiera. 


ES 


mente visibles una vez impresas. Gracias Luis. 
Después del proceso de impresión, lo utilizaremos 
una foto no sale nunca igual que el en la próxima 


fichero gráfico del que ha partido. A batalla. 
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delo son aún peores. 


Javier Perez Martin nos remite dos estupendas anima- 


sión de «3D Studio», estamos en ello. 


Jorge Reguillo de Luis 
también se apunta a la 
creación de mechs y nos 
envía una reproducción 
bastante exacta del famo- 
so dreadnought eldar de 
Warhammer 40000 y de 
la que incluye las mallas 
en formato 3ds. ¿Una crí- 
tica constructiva? Bueno, 
no tengo la miniatura en 
la que está basada el 
mech, aunque sí fotos de 
White Dwarf, pero yo di- 
ría que tu modelo está 


muy bien, aunque quizá te faltan algunas piezas en los 
hombros y algo de retoque en las manos. Claro que con lo 
difícil y agotador que es modelar manos convincentes no 


seré yo el que te eche esto en cara. Las de mi último mu- 


ciones y un cañón de barco del que nos pide una crítica 
feroz. Bueno, tal como dices, lo peor es la textura del 
agua. La boca del cañón resulta también algo extraña 


aunque el artefacto en sí no está mal. En cuanto a la ver- 


El Foro del Lector 


Ramón Rodríguez es 
otra víctima del virus 
infográfico. Domina 
otros programas como 


«3D Studio» y «Caligary», pero nos envía algunas escenas cons- 


truidas íntegramente con «POV>» e incluye algunas preguntas: 


1) ¿Cómo se pueden crear montañas con «POV»? Pues, aparte 
del método que has empleado, podías haber generado una TGA que 
sirviese como archivo de entrada para la sentencia heighttield, en lu- 
gar de dibujar la TGA a mano. 


Esto puedes hacerlo enfocando 
e iluminando perpendicular- 
mente un plano al que hayas 
puesto una textura adecuada. 
Otra posibilidad es usar alguna de 
las utilidades que existen para 
crear montañas como Terrain 
Maker u H£-lab (Rendermanía 8). 
2) En cuanto a la animación con «POV», este mes hemos co- 
menzado a tratar este tema. 
3) Y por último, en cuanto a la versión limitada de «3D Stu- 


dio», aún no la hemos publicado, pero nunca se sabe... 


De extremadamente inte- 
resante puede calificarse 
al POV-ipas T.N.T. ver- 
sión 2.0 remitido por Jo- 
sé Francisco García. Es- 
te trabajo es un archivo de 
tipo include que puede ser 
utilizado por los povmaníacos para explosionar sus obje- 
tos en tantos pedazos como sea preciso. José Francisco in- 
cluye, además, un completo fichero de ayuda para socorrer 
al sufrido usuario y unas prometedoras escenas de ejem- 


plo. Bueno, lo cierto es que ya dispongo de varios ficheros 


de este tipo, así que es posible que próximamente se haga 


un especial sobre IPAS explosi- 
vos en el que. por supuesto. parti- 
cipará esta utilidad. 


